简单和不需要 KISS YAGNI

KISS (Keep It Simple, Stupid) 和 YAGNI (You Ain't Gonna Need It) 是两个常见的设计原则，它们都强调简单性和避免过度设计。

KISS 原则 ​

KISS 原则（Keep It Simple and Stupid），翻译过来就是：保持简单，保持愚蠢,也有人称懒人原则

这个原则应用不仅仅是代码编程在各行各业都可以遵循

• 广告创意必须简单明了、纯真质朴、切中主题，才能使人过目不忘，印象深刻
• 产品设计产品中的零件数量越多，产品制造和装配就越复杂和越困难，产品制造费用和装配费越高，产品开发周期也就越长，同时产品发生制造和装配质量问题的可能性越高。在确保实现产品功能和质量前提下，简化的设计、更少的零件数量能够降低产品成本，缩短产品开发周期，提高产品开发质量
• 代码设计,保持代码可读和可维护,代码足够简单，也就意味着很容易读懂，bug 比较难隐藏。即便出现 bug，修复起来也比较简单可维护性较好

简单代码 ​

并不是代码行数越少就越简单，还要考虑逻辑复杂度、实现难度、代码的可读性，但如果问题本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则

* **防止代码腐坏**, 当越来的多人进入项目中，开发和维护随着逻辑越来越复杂，代码逻辑开始变得渐渐难以维护，保持KISS 原则可以防止代码腐坏

* **减少时间成本的投入** ，维护代码必然需要花时间修改、调试、理解内在逻辑并让代码正常运行，一旦代码非常复杂，势必会增加时间成本，保持KISS原则可以减少相应的时间成本

简单≠简单设计或简单编程，为了完成进度而做简单设计甚至不设计，认为只要后期有需要时再重构就行，编码时也就采用简单编程，并美其名曰迭代敏捷开发。但实际上，项目到后期几乎没有时间重构，并频繁出现问题（定位时间变长、逻辑嵌套过深、不断打补丁等），最后项目往往以失败告终。

简单应该是让别人理解代码逻辑时更简单

编写简单代码 ​

• 不要炫耀编程技巧，不要使用同事可能不懂的技术来实现代码
• 不要长期进行打补丁式的编码
• 不要重复造轮子，要善于使用已经有的工具类库
• 不要简单编程。 硬编码、一次性编码、复制粘贴编码、面向搜索编程都是简单编程，如果一直习惯性地简单编程，那么带来的可能就是更复杂、更高成本的重构和重写。这不仅不能提升代码扩展性，还会使得代码在后期无法被维护和重构。局部的简单导致整体的更加复杂，这是现在公认的一种得不偿失的做法。

YAGNI 原则 ​

YAGNI 原则的英文全称是：You Ain’t Gonna Need It。直译就是：你不会需要它。这条原则也算是万金油了。当用在软件开发中的时候，它的意思是：不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计,在确定真的有必要的时候再写代码，那时再重构仍然来得及

总结 ​

KISS（Keep It Simple, Stupid）和YAGNI（You Ain't Gonna Need It）是编程和系统设计中的两个重要原则，它们并非直接对应于某种特定的设计模式。而是通用的指导性原则，被用来引导设计决策以及编程实践

虽然 KISS 和 YAGNI 原则都强调简单性和避免过度设计，但它们的重点略有不同。KISS 原则强调保持代码简单易懂，而 YAGNI 原则强调只添加必要的功能，避免不必要的复杂性。简而言之，KISS 原则关注代码的可读性和可维护性，而 YAGNI 原则关注代码的精简和功能的必要性

KISS 和 YAGNI 原则适用于所有设计模式，不仅仅限于特定的一种或几种。其主旨是鼓励设计师和开发人员在设计和编程过程中追求简洁性，防止过度设计，并专注于当前的需求，而非预测未来可能出现的需求

写了好多的注释解释代码的执行逻辑，后续修改的这个方法的时候可能，忘记修改注释，造成对代码理解的困难。实际应用应该使用KISS原则，将方法写的见名知意，尽量容易阅读。注释不必过多。

参考 ​

设计模式之美

趣学设计模式